【レポート】CON409 – Deep Dive into Amazon EKS #reinvent #con409

AWS re:Invent 2017

#セッションレポート

#レポート

#Amazon EKS

#AWS

望月政夫

2017.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

re:Invent 2017 Keynote Day1で発表され大盛り上がりを見せたElastic Container Service for Kubernetes(EKS)。

【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent

AWSサービスの内側まで含めて詳しく聞けるDeepDiveセッションのEKS版「CON409 - Deep Dive into Amazon EKS」に参加してきました。そのレポートです。

セッション概要

Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a new managed service for running Kubernetes on AWS. Get a sneak peek into how Amazon EKS works, from provisioning nodes, launching pods, and integrations with AWS services such as Elastic Load Balancing and Auto Scaling.

アジェンダ

Amazon EKSのイントロダクション
KubernetesとAWS VPCのネットワーク機能
KubernetesとIAM
EKSの実演デモ
QA

Amazon EKSイントロダクション

Amazon EKSの根幹思想

使うのはupstreamのKubernetes、Kubernetesコミュニティにしっかり貢献していく
Production Workloadsに耐えうる信頼性の高いサービスを作る
AWSの各種サービスとの連携・統合
ECSでは以下のものを提供する
- フルマネージドなKubernetes master nodes &etcd
- Multi−AZデプロイによる高可用性クラスタのセットアップ
- より新しいKubernetesバージョンへのupgrade

EKSの処理の流れ

EKSで実際にコンテナを動かすまでに必要な作業は以下。

EKS Clusterを作る
Worker nodeを構築し、Clusterに加える。Worker nodeはEKSでは提供せず、ユーザー側がセットアップする必要がある（ECSと同様）
Kubernetesのアドオンを用意する
コンテナ(Pod)をデプロイする

上の手順1「EKS Clusterを作る」をもう少し分解すると、AWS側で以下の処理が行われている。

master nodeとetcdをMulti-AZでデプロイ
IAM統合機能(後述)とSSL証明書のデプロイ
master node & etcdのAutoScaling設定とLBへの組み込み

この処理内容は、ユーザ側が意識することはまったくない。EKSのユーザーに見えるのは、上記処理の成果物としてのLBのエンドポイントのみである。

EKSのネットワーク詳細

Kubernetesの持つネットワークとAWS VPCの持つネットワーク機能を統合するため、CNI(Container Networking Interface)のプラグインを自作した
- GithubでOSSとして公開し、Contributeも受け付けている。
  - aws/amazon-vpc-cni-k8s: Networking plugin repository for pod networking in Kubernetes using Elastic Network Interfaces on AWS
- CNI plugin導入による性能への影響は全くない
EC2の持つENIにSecondary IPを付与し、それをPodのIPアドレスと紐付ける。これにより、あるWorker nodeで動くPodから別のWorker nodeで動くPodへの通信が可能になる
このCNI PluginはECSだけではなく、自前でEC2上で構築したKubernetesクラスタでも利用可能
動作内容の詳細は以下の流れ
- CNI PluginをDaemonsetとしてデプロイすると、そのインスタンスにENIを作り出す
- Podを起動した時、vethが作成され、コンテナがホスト外のネットワークと通信できるようになる
- OS / Pod内のRouteTableを操作し、コンテナへの通信がvethに向くようにする
注意点としては、SecurityGroupはIPアドレス単位(Primary IP/Secondary IP)ではなくENIごとに設定される。SecurityGroupのRuleは注意して設定すること。

Kubernetes + IAM

この項目については、別のセッションリポートの内容とほぼ同じでしたので、そちらをご覧ください。

【レポート】Mastering Kubernetes on AWS #reinvent #CON308

Demo

実際にターミナル上でEKS上にPodをデプロイするデモが行われました。

当然といえば当然なのですが、Podの作成/情報確認/削除などは全てkubectlを用いて行われており、「あぁ、本当にAWSにKubernetesが来たんだ...」というのを実感することができました。

上述したCNI Pluginについても実際の挙動を置いながら説明されており、Worker node間での通信が行えることも示していました。

質疑応答

そのあと10分ほど、参加者との質疑応答が活発に行われました。

私が気になった質問として、「ENIのIPアドレス足りなくならないの？」という質問がありました。これに対してスピーカーより「インスタンスタイプ毎にアタッチできるENIの数/ENIに対して割り当てられるIPの数が異なる。制限に抵触しないよう、事前にキャパシティをある程度考えておく必要がある」という回答がありました。制限は以下のページから確認可能なので予めチェックをしておきましょう。